home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 428 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.8 KB
  1. Date: Sun, 12 Jun 94 15:43 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: gem-list@world.std.com
  4. Subject: Re:  Hello everyone...
  5. Precedence: bulk
  6.  
  7. I've been thinking alot about what's been said about KEYBOARD.SYS or
  8. SHORTCUT.SYS or whatever, the idea of a global short-cut file, etc.
  9. I'll have to agree with DMJ.  This file is a good idea, and it makes all
  10. the arguing over who's "standards" to accept just wasted bandwidth as
  11. the user can select his or her own "standards".
  12.  
  13. The name is definately wrong.  TOS 5 will have disk loadable keyboard
  14. translation tables, and while I really don't know what the name of such
  15. a file would be, there is a good chance it will KEYBOARD.SYS, so this
  16. would be a bad name for a hot-key file.  Also, the root directory is
  17. a bad idea.  And, unlike DMJ, I don't want yet another enviroment variable.
  18. Enviroment variables are a real pain for configuration purposes since they 
  19. get passed to EVERY application and they may never be needed.   
  20.  
  21. Therefore I would like to propose 2 different methods.  1-binary configuration
  22. of options.  This means having various standard symbols in the executable
  23. header's symbol table which would point to a string that would be modified
  24. by a standard "install" or "config" program.  By editing the "KEYPATH"
  25. symbol's data, you can have the application use ANY file or path as for the
  26. short-cut file.  This means all apps could use the same file, or you could
  27. make lots of separate files for each program, and you can put them anywhere.
  28. You can also have symbols like "RSCPATH" , or "STKSIZE" for the stack size
  29. in case you want that changed, and perhaps a few more.  A standard installation
  30. and configuration program would be highly useful and fairly easy to 
  31. implement in C or Assembly (I have no idea if you can mess with GFA BASIC's
  32. symbol tables).
  33.  
  34. The second method would be to have a standard directory for config files.
  35. Then an application could find read SHORTCUT.INF  <<I recommend this as
  36. the name>> from this path as well as application specific configuration
  37. files or options that would normally be put in an enviroment variable,
  38. such as LHARC's default options that get stuck in an ENVIROMENT variable.
  39. Only really global things like PATH, maybe SHELL, and TERMCAP (for you
  40. MiNT users) should go in the enviroment.  I don't think the enviroment is
  41. really the place for application specific information, but for GLOBAL
  42. information.   TOSRUN would be another example of a good enviroment 
  43. variable, and maybe the location of the configuration directory could be
  44. an enviroment variable, but not the configuration info itself.
  45.  
  46. ABout the cookie jar.  What are you going to put in there?  It seems like
  47. a bad place, not because of space limitations or "wasting cookies" but
  48. because it just doesn't seem useful to have a cookie there.  What for?
  49.  
  50. CYA
  51. ekl@sdf.lonestar.org
  52.  
  53.  
  54.